【Day 1】開賽宣言：為什麼我們需要把「寫報告」變成「寫程式」？

前言

如果你也在公司負責日報、週報這類例行性報告，一定有過這種經驗：資料東拼西湊、格式每次都要重新對齊、寫到一半突然想不起來上週是怎麼措辭的。

這系列文章要挑戰的事情很單純：用 AI 把「寫報告」這件重複性工作，變成一套穩定、可重複執行的系統。

但在動手寫任何一句 prompt 之前，我想先花第一天，把心態校正好。因為這 30 天最大的風險，不是技巧不夠，而是一開始就把 AI 想錯了——你不是在跟 AI「聊天」，你是在「寫規格」。

一、拆解「寫報告」的本質

我們先把「寫日報/週報」這件事拆開來看，會發現它其實是三個階段的組合：

① 收集資料 → ② 判斷 / 整理成有意義的內容 → ③ 排版成公司要的格式

多數人以為「寫報告」是一件不可分割的整體工作，但拆開後會發現：這三段裡，只有②真正需要人的判斷力，①和③本質上是機械性的重複勞動。

• ①收集資料：每天/每週固定去監控平台撈資料，操作步驟幾乎不變
• ③排版格式：標題怎麼下、章節順序、慣用措辭，公司格式一旦定案就是固定的

這正是自動化的切入點——我們要做的不是「教 AI 學會寫作」，而是把①和③變成明確規則，只留②交給 AI 去做真正需要判斷的部分。

二、「寫程式」與「寫報告」的共通邏輯

寫程式的核心精神只有一句話：同樣的輸入，永遠得到同樣邏輯處理過的輸出。 一個函式不會因為今天心情不好就算錯結果。

而我們現在要對 AI 做的事，其實就是這個邏輯的翻版：

差別只在於：寫程式用的是嚴謹的程式語法，而我們現在用的是「自然語言」當作程式語法。這也是為什麼這門技術叫做 Prompt Engineering——重點在 Engineering（工程），強調的是可靠、可重複、可驗證，而不是「靈感」或單純的「聊天技巧」。

三、破解一個新手最容易踩的迷思

「AI 很聰明，應該看得懂我大概想要什麼吧？」

這句話,是這整套方法論最大的陷阱。實際狀況是：

• AI 沒有「記得你上次想要什麼」的能力，除非系統特別設計了記憶機制
• AI 不會主動反問你「你這邊的意思是不是⋯⋯」，它只會用「統計上最可能的猜測」直接生成答案
• 你講得越模糊，它填補空白的方式就越不可控——今天猜對了，不代表明天也會猜對

所以「規格書思維」具體的做法是：把你腦中對「一份好報告」的所有隱性假設，翻譯成範本裡明確寫出來的規則。 你心裡認定的「這段要精簡一點」「這裡語氣要正式」「這種情況要特別註明」，這些你自己知道、卻從沒說出口的標準，都必須在範本裡清楚寫下來——因為 AI 讀不到你的心裡話，它只讀得到你打出來的字。

四、給讀者的行動練習

在進入下一篇之前，建議你先別急著寫 prompt，拿出一份自己過去手動寫過的日報或週報，回答三個問題：

1. 哪些部分，不管哪一週，結構永遠一樣？（這會是範本未來的固定骨架）
2. 哪些部分，是我當下看資料才決定要寫什麼的？（這是 AI 之後真正要做判斷、也最需要謹慎設計 prompt 的地方）
3. 有沒有哪一次，主管或同事看完報告說「這裡怪怪的」？為什麼怪？（這通常代表你心裡藏著一個從沒說出口的隱性標準）

這三題的答案，會直接成為後面「拆解範本骨架與血肉」以及「定義輸出規格」兩篇文章的素材。

小結

今天沒有寫任何一句 prompt，因為在寫規則之前，我們得先確定：自己有沒有把 AI 當成一個需要明確規格書的產線員工,而不是一個「應該懂我意思」的聊天對象。

這個觀念沒建立好,後面再多的框架與技巧,都只是在一個不穩的地基上疊房子。

下一篇,我們會正式進入 Prompt Engineering 的心法：它究竟在解決什麼問題？「穩定性」與「可重複性」這兩個詞,具體又是指什麼？